Hi All,
Ok. How does one go about finding the parenthesis within a string or a buffer?
I know that it's ascii code is 40.
ALso, what in the world are \m,\j, \k??
I see these are in the "space" class of char.
I have not found anywhere so far what they mean.
I aslo have not found anything about the parenthesis.
Do we use the "\" with it like in regexp?
I know how to find the period \\.
I would suspect the dash is \\-, but I am not sure yet.
I was looking for the "(" first, and the other too ")".
I am sure you guessed by now that I am going to start parsing/validating phone numbers.
I do have to worry about international numbers, so this will be a bit tricky.
I might handle them with two different regexp, but I am not sure yet.
I just want to find the "("!!! :)
Jerry
SystemAdmin - Mon Aug 01 15:20:33 EDT 2011 |
|
Re: Find Parenthesis??
SystemAdmin - Mon Aug 01 15:36:27 EDT 2011
Oh it figures. I post here and then I did another search and I found what I was looking for
about the paranethesis. Damn murphy's law!!
So, I think I answered my own question. But feel free to respond. I love have fresh new ideas. :)
Jerry
|
|
Re: Find Parenthesis??
llandale - Mon Aug 01 18:01:34 EDT 2011
The 'char' version of buffer "contains" works well, but the string version has restrictions making it pretty hopeless.
...int Location = contains(buf, '(', 0)
should work. Check for Location < 0.
\m \j \k are illegal codes, the DXL manual has never been updated. Hard to believe those references are still in there after all these years. These codes are valid:
... \t\n\v\f\r
yes, regular expression characters such as parens must be escaped when used literally. DXL requires the escape slash to be escaped as well, so you do this: "\\("
Well, if you are translating character strings into phone numbers and can allow many types of format then its more difficult. If you think you can define all your valid formats then Regexp may be the way to go. Otherwise I'd be tempted to remove from the string all non-numeric characters and then apply sanity rules, perhaps:
o If first digit is not zero then it must be exactly 10 digits (US numbers)
o If first digit is zero then I don't know what to tell you.
After you detect a valid number, then re-format it into whatever your standard is, perhaps: (123)456-7890 for US.
|
|
Re: Find Parenthesis??
SystemAdmin - Tue Aug 02 16:51:27 EDT 2011 llandale - Mon Aug 01 18:01:34 EDT 2011
The 'char' version of buffer "contains" works well, but the string version has restrictions making it pretty hopeless.
...int Location = contains(buf, '(', 0)
should work. Check for Location < 0.
\m \j \k are illegal codes, the DXL manual has never been updated. Hard to believe those references are still in there after all these years. These codes are valid:
... \t\n\v\f\r
yes, regular expression characters such as parens must be escaped when used literally. DXL requires the escape slash to be escaped as well, so you do this: "\\("
Well, if you are translating character strings into phone numbers and can allow many types of format then its more difficult. If you think you can define all your valid formats then Regexp may be the way to go. Otherwise I'd be tempted to remove from the string all non-numeric characters and then apply sanity rules, perhaps:
o If first digit is not zero then it must be exactly 10 digits (US numbers)
o If first digit is zero then I don't know what to tell you.
After you detect a valid number, then re-format it into whatever your standard is, perhaps: (123)456-7890 for US.
char version of buffer??!! I did not you could have that!
wow, I learned something new. But, I am very new to DXL.
Yeah, phone numbers are going to be really fun becasue:
1) multiple countries
2) no standard when entering
3) no mask or input filtering of any kind
So, I end up with phone number like these:
Ex. 1-616-451-8488, (616)451-8488, +1.616.451.8488, 616 451-8488, +1 (616) 451.8488
I think you get my drift. And sometimes there might be a space somewhere within by accident.
And then I have the UK users to worry about, and I have users in CHINA.
I had one today from China that did not give me any country code or such, just an 8 digit number.
So, I have no clue what area to use even though I know the country code.
And I cannot assume it is just like the other person that was created shortly after.
So, this is going to be really fun!!! :)
Thanks for the input!
Jerry
|
|
Re: Find Parenthesis??
llandale - Tue Aug 02 18:29:16 EDT 2011 SystemAdmin - Tue Aug 02 16:51:27 EDT 2011
Hi Louie, I was hoping you would chime in! :)
char version of buffer??!! I did not you could have that!
wow, I learned something new. But, I am very new to DXL.
Yeah, phone numbers are going to be really fun becasue:
1) multiple countries
2) no standard when entering
3) no mask or input filtering of any kind
So, I end up with phone number like these:
Ex. 1-616-451-8488, (616)451-8488, +1.616.451.8488, 616 451-8488, +1 (616) 451.8488
I think you get my drift. And sometimes there might be a space somewhere within by accident.
And then I have the UK users to worry about, and I have users in CHINA.
I had one today from China that did not give me any country code or such, just an 8 digit number.
So, I have no clue what area to use even though I know the country code.
And I cannot assume it is just like the other person that was created shortly after.
So, this is going to be really fun!!! :)
Thanks for the input!
Jerry
... int contains(Buffer b, char ch ,int offset)
... int contains(Buffer b, string word, int offset)
I'm suggesting the 2nd one is practically worthless "...provided the string is preceded by a non-alphanumeric character". I think that's for looking for key words in a program. If the buffer is "ABC DEFG" it will find "DEFG" but not "EFG".
You can use the char version to find individual characters.
If you go the RegExp route you will need to anticipate all the reasonable ways someone may unreasonably enter their phone number; surely Murphy's Law will dominate that effort. For example, I once saw this: 451-8488(616); or was it this: 451-8488;616.
I think you need to just strip away all the non-numeric characters leaving "6164518488"; then count the characters and try to force it into a prettier format "616-451-8488". If it does not start with a zero or a one then perhaps, remotely, you could use the user's "Locale" to figure out the country code and prefix that "1-616-451-8488". That seems reasonable if all the numbers were in the nice exactly 10 character US format but good luck with all the other countries and other length of numbers, especially since some countries have two layers of "area codes" and local folks tend not to consider them; and of course you don't know for sure the country. Seems daunting to create a huge lookup table based on Locale showing coutry-codes and possible province-code and local-number lengths correctly.
I would add a label "If you want to get a phone call then type in your dang number correctly", effectively changing the requirements.
Thinking out loud: associate a callback with every DBE on the dialog that checks the phone number and attempts to figure it out. It puts back in the phone number DBE its best guess at proper formatting. It displays its opinion on whether the program believes the phone number is well formed, and encourages the user to fix it if not. Perhaps the "Apply" button can add an extra confirm about poorly-formed phone numbers. The program remembers the last re-formatted phone number it checked and the callback will do nothing if the number DBE hasn't changed.
|
|
Re: Find Parenthesis??
David_G_Bond - Wed Aug 03 10:41:43 EDT 2011 llandale - Tue Aug 02 18:29:16 EDT 2011
There are two commands called "contains" looking for stuff in Buffers, one looks for a "char" and the other for a "string":
... int contains(Buffer b, char ch ,int offset)
... int contains(Buffer b, string word, int offset)
I'm suggesting the 2nd one is practically worthless "...provided the string is preceded by a non-alphanumeric character". I think that's for looking for key words in a program. If the buffer is "ABC DEFG" it will find "DEFG" but not "EFG".
You can use the char version to find individual characters.
If you go the RegExp route you will need to anticipate all the reasonable ways someone may unreasonably enter their phone number; surely Murphy's Law will dominate that effort. For example, I once saw this: 451-8488(616); or was it this: 451-8488;616.
I think you need to just strip away all the non-numeric characters leaving "6164518488"; then count the characters and try to force it into a prettier format "616-451-8488". If it does not start with a zero or a one then perhaps, remotely, you could use the user's "Locale" to figure out the country code and prefix that "1-616-451-8488". That seems reasonable if all the numbers were in the nice exactly 10 character US format but good luck with all the other countries and other length of numbers, especially since some countries have two layers of "area codes" and local folks tend not to consider them; and of course you don't know for sure the country. Seems daunting to create a huge lookup table based on Locale showing coutry-codes and possible province-code and local-number lengths correctly.
I would add a label "If you want to get a phone call then type in your dang number correctly", effectively changing the requirements.
Thinking out loud: associate a callback with every DBE on the dialog that checks the phone number and attempts to figure it out. It puts back in the phone number DBE its best guess at proper formatting. It displays its opinion on whether the program believes the phone number is well formed, and encourages the user to fix it if not. Perhaps the "Apply" button can add an extra confirm about poorly-formed phone numbers. The program remembers the last re-formatted phone number it checked and the callback will do nothing if the number DBE hasn't changed.
|
|
Re: Find Parenthesis??
llandale - Wed Aug 03 14:44:29 EDT 2011 David_G_Bond - Wed Aug 03 10:41:43 EDT 2011
I respectfully disagree that the second form is nearly worthless. If you are looking for specific words (such as 'shall') you do not want to be fooled by words that contain those letters in the same sequence (such as 'marshall'). I have used the second form in many cases to search for matching words when looking for similar requirements. I harvest the words in one requirement and look for other requirements that match some percentage of the words. It is very useful
I suppose, however, you could get a performance improvement by first using "contains" and if found, then doing a more rigorous RegExp match.
Seems "unusable" for 100% objective searching, but for Google style fuzzy "what's a good fit" stuff that you doing then perhaps its indeed good enough; although I suspect that more exact or less exact matching would work better for you (find both "marshall" and "shallow", or neither).
|
|